Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

Creating a static SBO

You create an SBO from the New dialog box.

To create an SBO:

From the AppBuilder main window, select New Dynamic SmartBusinessObject. The New dialog box appears, as shown:



The SBO Wizard prompts you for the same sort of documentation information as for other objects, and then leaves you in a nonvisual design window.

Select the SDOs that you need to group together from the AppBuilder palette. Drop them onto the SBO design window in their top-down or header-detail order. For this example, use the SDOs for the Order and OrderLine tables created by the Object Generator, orderfullo.w, and orderlinfullo.w, as shown:



When you drop the second (and any succeeding) SDOs onto the SBO, the AppBuilder’s Link Advisor prompts you to let it create a Data link between SDOs. Confirm that the link is appropriate, then accept the link as presented by the Progress Advisor dialog box, as shown:



Alternatively, add links of your own after adding the SDOs. There must be a data link from the Order SDO to the OrderLine SDO in the example.

For each data link, you are prompted for the foreign key fields to use to filter the query of each SDO based on data from the Data-Source, as shown:



Choose OK. The Multi-Field Mapping dialog box appears, as shown:



Choose the appropriate fields from each SDO. In the example, the OrderNum field links the two SDOs.
Save the SBO and give it the name you used in the documentation page of the wizard. Name the example SBO orderlinesbo.w.

Because the Order SDO has no Data-Source, it is automatically made the MasterDataObject of the SBO in the example shown:

Note: In the Instance Property dialog box for each SDO, you can change the ObjectName property if you wish, along with other properties such as RowsToBatch. (In this example, the ObjectName property is called Instance Name to distinguish it from the object name of the variable holding the handle of the SmartObject—used elsewhere in the AppBuilder windows.) It is not meaningful to set the partition for the SDO. The Partition property of the SBO determines the AppServer connection, if any, so this field is disabled.

The Update from Data Sources check box is a property used for SDOs in SBOs. If you use the SDOs in the SBO in a one-to-one relationship where they all represent different parts of a single logic record (such as Customer Header, Address, and Detail Information tables for example), then this should be checked for all SDOs except the master. This will allow them to be updated and all changes committed to the database together just by choosing the Save button in a toolbar, rather than requiring a Save and a separate commit. In other words, this toggle box tells the SBO to initiate an update from this SDO’s Data-Source (the master SDO), rather than saving its changes separately.

In the case of a master-detail transaction where there might be two or more detail records added or modified together with a single master record, the changes all must be saved separately on the client and then committed together to the server. In this case, leave the Update from Data Source toggle box unchecked and include Commit and Undo buttons (the Transaction band available on the standard toolbar and other toolbars) in your window.

Page 0 (the background page) and Page 1 are displayed when the window comes up, as shown in Figure 11–8.

Figure 11–8: Example window—Pages 0 and 1

The SBO has retrieved the first batch of Orders through the Order SDO, and in the same operation, the OrderLine records for the first Order. If you modify a field in the Order viewer and Save that change, the Commit and Undo buttons are then enabled to let you send that change back to the server. Remember that when the Commit band is in your toolbar and there is a Commit link from the toolbar to a data object such as your SBO, all changes will be held in local temp-tables on the client until you choose Commit. If you choose Undo, all these changes are deleted.

Select the Lines tab to see the OrderLine records for the currently selected Order, as shown in Figure 11–9.

Figure 11–9: Example window: OrderLine records

You can make changes to one or more OrderLine records here and save those individually. Then choose Commit to send all the changes to both tables back to the server.

The objects in the window attempt to prevent a user from doing inappropriate things when there are uncommitted changes. For example, after making a change to an OrderLine and returning to Page 1, the browser and the toolbar will not let you select another Order until you commit your changes. This is because changing Orders would retrieve a new batch of OrderLine records from the server, and your changes to the OrderLine records for the previous Order would be lost. Keep in mind that a set of changes committed together for this type of parent-child relationship must be for a single parent record and one or more of its child records.